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Executive Summary 


Collaboration between technology 

part of good information 

organizations' technology, those 
working with the researcher 

collaboration across the digital 

Administration (NTIA) convened 

around security researcher 


providers and security researchei 
security. As security researchers 
organizations benefit from 
to understand and mitigate 

ecosystem, the National Tele^ 
a multistakeholder process to 

disclosure. 


This document reflects the work 

steps an organization can take 

open, transparent fashion, with 
security community. Much 

potential for harm directly 

or medical devices), but the 

maintains its own software 


of the "Safety” working 

to improve collaboration, 
diverse participation from 

of the discussion targeted 

impacts public safety or 

lessons are easily adaptable 

or systems. 


groi 

It 

the 

cauj 

by 


In this report, we discuss why 
industries that are becoming more and 

present a template disclosure policy, 
for "Acme Corp.” At the end of 
should consider when developing 


security disclosure is 

more dependent 

explain the different 

this document, we 

a security disclosure 


imp< 

on 

sect 

walk 

polic 


1 The Working Group is soliciting public comment on this draft, and inter 

feedback to: afriedman@ntia.doc.qov to pass alonq to the workinq qroup. 

2 

More information on NTIA's open Multistakeholder Process to Promote 

process is available _at_ https://www.ntia.doc.gov/other-publication/2016/m ultistakeholder-process-cv 

vulnerabilities. 
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Introduction: Disclosure and Safety 


Safety-critical systems are increasingly dependent on software, 

subject to software security issues. Coordinated vulnerability 
attention into improving the safety and security of systems and 

population. Compared with traditional IT systems, manufacti 

a higher consequence of failure and relatively less experieno 
trust, high collaboration interactions come from understan 

perspectives. 


We define "safety-critical industries” as those in which 

humans - for example, an automobile, an embedded mec 

insulin pump), or carbon monoxide detectors. Compared 

differences that must be appreciated and 3 accountfflcHI impafctr. Time 
than just disclosure policies and actions (by multiple stakeholders); 
consider how design choices will limit or grant cape 

vulnerabilities. 


Consequences: When 

software is a dependency 

for 

safe 

consequences of security 

failure may 

manifest 

in 

dire< 

of life. 

Impacts from 


wide-scale harm 


can 

shatter 

and can 

damage trust 


in government 

and 

its 

role 

safe 

and regulation. 







Adversaries: 

Different 

adversaries have 

different 

goals, 

capabilities. 

While 

some 

adversaries 

may 


be 

dete 

impacting 

systems, others 

may seek 

these 


systems 

may wish 

to inflict 


harm, and criminal 

groups 

may 

ransoms. 








Composition: 

Some 

components in Internet 

of 

Things 

are not 

found in 

typical IT environments. 

Elements 

suet 

controllers, 

low power 

chips, 

embedded 

controllers, 


limit 

capabilities 

available to 

the 

manufacturer in 

design 

and 

resp 

Economics: 

Components 

for 

safety systems 

may 


require 

protect 

and have 

a 

very low cost 


of 

goods, 

Security 

capabilities 

for 

million—dollar data 


centers 

are 

microchips, 

for example. 







Context 

and Environment: 

Safety-critical systems 

often 


ex is 

environmental, physical, 

network, immediacy/real-time, 

and 

legal 


Am the 

Cavalry. "6 

Differences in Internet 

of 

Things 


and 


i 

https://www.iamthecavalry.org/iotdiffere nces/ 
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instance, a pacemaker is implanted in a human 

immediately, has no bolt--on security measures, and carr 

requirements. 


• Timescales: Timescales for design, 

retirement are often measured in 

because of composition, context, 
be with us for 10, 20, 40, 


development, implementation, 

decades. Response time 
and environment. Safety 
or more years. 


Vulnerability 
due haste 
vulnerability 
consequence 
trust; at 
increase 
implanted 
long and 


disclosure and 
and due care, 
has not been 
failures may 
same time, 
Decisions 
device, 
to 


the 
risk, 
medical 
too short 


remediation 

in 

cyber 

safety 

cont 

Researchers 

may 

be more 


(or cannot 

be) fixed. 

On 

the 

motivate 

action. Remediation 

urge 

validation 

and 

verification 

avoid 


considered 

insecure for 

a web 


Any hard 

deadline for 

disclosure 

or 

safely address 

security 

vulnerabilities 


We believe Coordinated 

safety-critical industries, 

to security research 

softened fear of legal 
vulnerability research 

should understand 

themselves with a 


on 


Vulnerability Disclosure is especially 

DMCA rawtebh exemoVens significant 
and medical devices, went 
higher numbers of researchei 
in safety-critical industries, 

security research community 

of tools to successfully 


cars 
concerns, 
and disclosure 
how the 

flexible set 


Disclosure Policy: Th e First Steps 


Stakeholders 

representing 

a 

range 

of 

interests 

in 

this com 

approach that 

starts 

small 


to build 


experience, 


confident 

contemplating 

their 

first 

steps 

into 

Coordinated 

Vulnerability 

and references 


from 

multiple sources 

available 

to 

consult 

journey has 

taken 

many 


years 

for 

even 

the 

most 

What follows 

is 

a simple 

framing 

of 

what 

an 

"early 

might look 

like. 

Below, 

we present 

a template 

of wha 

disclosure policy 

might 

look 

like 

and 

then 

highlight som 

policy. We 

also 

present 

a 

sample 

disclosure policy. 
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US Copyright Office. "Exemption to Prohibition on Circumvention of 

Technologies" 80 FR 65944 _ (2015). Available _at:_ https://w ww.federalreqister.qo' 

27212/exemption-to-prohibition-on-circumvention-of-copvriqht-protection-svstems- for-access-control 
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There are 

including 

produced 

Disclosure 

disclosure, 

organizations 


many resources on 

ISO/I EC Standards 5 * 7 

by stakeholders in 

Attitudes and Actions: 

and "Guidelines and 

facing more 


how to 

29BOT7 morand 
the NTIA 
*A Reffiffidrrch 
Practices for 


think about vuln 

30iliidr.mation, two ot 
process may be 

Reiprante'' background 
Multi-p'arty foiVulnerabil 


complex disclosure challenges. 


5 ISO/IEC 29147 "Vulnerability Disclosure" (2014) _ http://www.iso.org/iso/c ataloque detail.htm?c 

standard is p ublicly available at: http://standards.iso.o rq/ittf/PubliclyAvailableStandardsy 

"Vulnerability Handling Processes" (2013) can be be found at 

http://www.iso.org/iso/cataloque detail.htm?csnumber= 53231 

g 

"Vulnerability Disclosure Attitudes and Actions: A Research Report" (201 

https://www.ntia.doc.gov/files/ntia/publications/2016_NTIA_A_A_vulnerability_insights_report.pdf 

7 "Guidelines and Practices for Multi-party Vulnerability Coordination" (2016). This 

https://www.first.org/global/sigs/vulnerability-coordination/multiparty 
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Template 


Disclosure 

Policy 




The first 

step 


an organization should take 

is to 

dev< 

policy. 

We 

urge 

the 

creation/use 

of a 

simple, short 


readable 

page. 


Many 

organizations, 

including 

automakers 

and 

already 

done 


this, 

leveraging 

the template below. 





Brand Promise 




Objective: 

To 

demonstrate 

a clear, 

good 

faith commitme 

stakeholders 


potentially 

impacted by 

security 

vulnerabilities. 


Audience: 

Customers 

and 

the market 




Tone: 

Committed, 

concerned, and 

open. 

For instance, 

"The 

is important 

to 

us...” 





Content: 

Assure 

customers 

and the 

market 

that safety 

and 

work has 

already 

been 

done as 

well as 

future commitme 

reporter 

can 

serve 

as 

outreach and 

can build 

trust 

up 

this program 

to 

give 

security researchers 

a point 

of 

research 

findings, 

which 

can then 

be remediated in 

a 


Initial Program a nd Scope 


Objective: 

To outline 

which 

i systems 

and capabilities 

are 

"fair 

initial program, which 

will 

evolve 

as 

capacity and 

confidence 


Audience: 

Vulnerability 

finders and 

reporters 



Tone: 

Set a reasonable 

initial 


phase to 

build 

cape 

Content: 

Declaration 

of 

explicit 

and/or implicit 

scope, 

and 

scope. 

Explicit scope 

sets 

an 

expectation 

for what 


reports, 

such as 

models/years 

and 

versions as 

well as 

dure 

recognition 

and/or reward, 

allows 

a 

degree of 

throttling 

of 

and can 

be expanded 

over 

time 


as well. 

Optionally, 


unintended 

harm from 


good 

faith 

research, 

though 

a 


"We 

Will 

Not Take 


Legal Action If..." 


Objective: 

To assure 

that 

vulnerability 

finders and 

reporters 

of 

their good 

faith 

acts. 






Audience: 

Vulnerability 

finders and 

reporters 



Tone: 

Non-threatening, 


inviting, 

and 

reasonable, 

using 

lang 

without 

a legal 

background 

or 

representation. 

Affirmative 


than prohibitive, with 


some 

key 

exceptions 

such 

as 


Content: Clear, unambiguous statements that guide researchei 

should tell researchers what activities will and won't resu 
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evergreen and is very unlikely to change. This section 

from deviating. 

Other Considerations: This section should contain lega 

priorities, which will come later. Parties should account 

national/federal laws. 

Communication Mechanisms and Process 


Objective: To clearly identify communication mechanisms and reas 

timeframe. 

Audience: Vulnerability finders and reporters 

Tone: Reasonable for the initial information exchange 

Content: Define a mechanism for submission and reporting, 

(such as a PGP encryption key) and requirements for com 

from a legal posture). Many organizations prefer a seci 

set expectations for when the researcher can expect to 

submission and how future engagement/communication will take 

outline conflict resolution mechanisms and roles and responsibi 


Nonbindinq Submission 


Preferences 


and Prioritizations 


Objective: To set expectations based on priorities and submissio 
legal objection or restriction. 

Audience: Vulnerability finders and reporters 

Tone: How bugs will be triaged/prioritized 

Content: This section is a living document that sets 

typically maintained by the support and engineering team, 

vulnerabilities, reporting style (crash dumps, CVSS scoring, 

Too many preferences can set the wrong tone or mak 

This section also sets expectations to the researcher com 

considered important or not. 


Versionin g 


Objective: To track the evolution 

Audience: Vulnerability finders and 

Tone: Organized to help 

adjustments to the policy. 

Content: This optional section 

how it might evolve in the 


of the policy, 
reporters 

the researcher understand 

can help the reader und< 

future. See "Changing the 
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ACME Corp., the leading manufacturer of embedded software 

ensuring the safety and security of our customers. Toward 

our policy for accepting vulnerability reports in our products, 
partnership with the security community, and we recognize that 

is important in continuing to ensure safety and security 

We have developed this policy to both reflect our 

responsibility to good--faith security researchers that are prov 

Initial Program and Scope 

Initial Scope 

ACME'S Vulnerability Disclosure Program initially covers the 

• ACME Widgetsoft 3.1 

• ACME Widget Module A 

• ACME Widget Module B 

• ACME Widget Controller 

• ACME Widget Ethernet Gateway Module 

While ACME develops a number of other products, we ask 

vulnerability reports only for the stated product list. We 

build capacity and experience with this process. 

Researchers who submit a vulnerability report to us 

the submission has been accepted and validated by our proc 

We Will Not Take Legal 

Legal Posture 

ACME Corp will not engage in legal action against indi\ 

through our Vulnerability Reporting Form. We openly accept 

ACME products. We agree not to pursue legal action agai 

• Engage in testing of systems/research without harming 

• Engage in vulnerability testing within the scope of 

and avoid testing against [ex. website]. 

• Test on products without affecting customers, or receive 

customers before engaging in vulnerability testing against 

• Adhere to the laws of their location and the loca 

laws that would only result in a claim by ACM 
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acceptable as ACME is authorizing the activity (reverse 

protective measures) to improve its system. 

Refrain from disclosing vulnerability details to the publ 

timeframe expires. 


Communication Mechanisms 


How 

To 

form 

to Submit 

submit a 

<link to 

a Vulnerability 

vulnerability report 

vulnerabflity reporting 

to ACME'S Product 

form> 

Nonbinding Submission 

Preference, Prioritization, and Acceptance 

Preferences 

Criteria 

We 

will use the 

following criteria to 

prioritize 

and triage 

What 

we would 

like to see from 

you: 



and Pr 

Seci 


and F 


subr 


Well-written 
Reports 
Reports 
lower priority. 


reports 
that include 
that include 


in English wil 
proof-of-concept 
only crash 


have 

code 

dumps 


a higher 

equip us 
or other 


• 

Reports 

that include 

products 

not 

on the 

initial scope 

• 

Please 


include 

how 

you 

found 

the 

bug, the 

imp; 

• 

Please 


include 

any 

plans 

or 

intentions 

for public 

disc 

What 

you 

can 

expect 

from 

us: 





• 

A 

timely response 

to your 


email 

(within 2 

busi 

• 

After 

triage, we 

will 

send 

an 

expected 

timeline, and 

com 


possible 

about 

the 

remediation 

timeline 

as well as 

on 


extend 


it. 







• 

An 

open 

dialog 

to discuss 

issues. 



• 

Notification 

when 

the 

vulnerability 

analysis 

has completed 


• 

Credit 


after 

the 

vulnerability 

has been 

validated 

and 

If 

we 

are 

unable 

to 

resolve 

communication 

issues or 

othe 

neutral 

third 

party 


(such 

as 

CERT/CC 

,ICS—CERT, 

or 

determining 


how 

best 

to 

handle the 

vulnerability. 










Versioning 


This 

document 

Version 

1.1 

was created 

15-December-2016. [We 

updi 

every 

90 

days.] Any 

updates will 

be 

noted 

below in 

the 
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For an example of 

https://vulcoord.cert.orq/VulReport/fo rm 


secure 


web form, see cert.org's 


Vulnerability 
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Issues 


to Consider 


in Writin g a Disclosure 

Defining Vulnerability Disclosure Program Scope 

Any newly implemented vulnerability disclosure program may 
unanticipated volume of submissions. In the early stage, 

explicit or implicit scoping in the disclosure policy. This 
the specific type of disclosure items the company is prep 

capacity and experience. 

For example, submissions could be explicitly scoped by limit 

• Only specified product model years 

• Only select product make/model/year 

• Only particular types of vulnerabilities 

Implicit scoping may be influenced by the type, strue 

awarded to researchers, if any incentives are used at 

particular area for finding security issues is one way of 

scope may come from the reward structure. A Coordinat( 

with no reward program is likely to attract altruistic indi\ 

their findings with the company, but are not looking for a 

and/or a reward to the program could expand the scop 

Rewards such as providing recognition on a wall of farm 

and/or branded merchandise attracts some researchers to 

rewards will attract researchers as well, and will be less 

limit the response from the research community. 

Researchers are motivated to understand security flaws 

desire to solve an interesting problem to a desire 

illustrates some of the diverse types of motivations rese 

narrowing the scope and/or having no financial incentive for 
limiting the number of reported vulnerabilities; and attracting rese 

patience and/or less motivation to disclose during conference 

deadlines), the dates of which could conflict with the 
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Table 


Researchers 


Protect 


Puzzle 


Prestige/Pride 


Diverse Motivations 

MoliiDetiofiption 


of 


Security 


Researchers 


Profit/Professional 


Politics/Patriotism/Proteftldeological or 

anti-- causes 


Wants to 

to realities 


make the world 
affecting safety. 


Tinkerers, curiosity, hobbyists. 


Driven 


Recognition, 


making 


name, 


Seeking 


monetary reward 


and/or 


principled. E.g. Civil 

or organizations. 


safer 


by 'Ho 


conference 


making a 
liberties. 


In summary, 

an organization can 

use explicit 

and 

implicit scop 

capacity to 

implement 

its disclosure program. 

As 

the 

organizatii 

experience through responses 

to 

vulnerability 

disclosures, 

it 

With maturation 

of the 

organizational response 

capabilities. 

, expl 

limitations may 

be relaxed so 

that more 


useful 

disclosure 

vulnerabilities 

that fall outside the 

program 

scope 

may 

still 

and response. 

Programs should be 

prepared 

for 

such 


a cont 

well-intentioned 

finders who 

are 

aware 

of 

a 

vulnerability 

the current 

policy. 







Changing the 

Disclosure 

Policy 






As with 

any policy, 

at some 

point, 


it 

may 

nee< 

changing the 

disclosure policy 

r is 

that it 

can 

make 


things 

difficult for 

vendors to 

track, 

or can 

cause 

researchers 

As such, 

we recommenc 

1 minimizing 

changes 

if 

possible. 

legal protections 

offered 

to researchers 

should 

not 

change 

maintained. 








Given that policies may 

change, 

some 

strategies 

to 

maintain 

• Be transparent 

explain 

why 

the 

disclosure 

policy 

O Accept 

feedback 

on changes / 

listen 


to 

the com 

• Explicit 

duration of 

any given 

policy: 

This 


policy 

• Include 

version control 






O For 

any change 

made; 

archive 

prior 


versions (con 

the 

organization's 

site) 
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I 


Am The Cavalry. 


"5 Motivati ons of _ Security R esea rchers." Available 
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O Avoid abrupt or erratic changes in the policy, and 

time periods 

• Consider allowing researchers to enroll, and become grar 
version 

O This puts a lot of responsibility on to the rese 

which policy version is being used 

O [Light version: have a feed or email list for 

• Include explicit caveats about how the policy will 

O This may result in a very long and com 

O Black lists will invariably grow 

O Potential solutions: white listing (allowed) over blac 

• Declare certain parts of the policy immutable, part 

promises 

O Have a baseline - everything above this point 

■ Baseline = white list (allowed) 

■ Consider tying in with brand promise 

■ Should reflect high level goals of proc 

rather than technical approaches 

■ Changes to white list (adding or removing) 

accompanied with an explanation for the char 

O Here is the section that we may change - esta 

■ Changing = black list 

■ May be used to throttle common or "low 

■ May change as a result of enhanced security 

■ May be used to shift the focus to the 

O Can encourage researchers to check back, and 

the research against (in good faith) to grandfath< 

O Can subscribe to an RSS feed of updates 

Resolving these issues will help inspire confidence amc 

success of the policy. 


Restrictions on Disclosure 

Researchers do not create vulnerabilities. The fact that one rese 

existence does not guarantee that another will not find it 

may have reasons to want to disclose the vulnerability 

motivations discussed above. A managed disclosure situation is pref 
control. Vendors may want to express preferences on 

vulnerabilities. A few options are: 

Do not publicly disclose: 

1. Until it is fixed 
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2. Until a particular 

timeframe 


after 

first 

submission 


3. Until after 

giving 

the 

organization 

X 

days 


of notii 

4. Mutually agreed--upon 

(or 

negotiated) 

timeline 

(as 

discussed 

technologies 

or 

sectors 

may 

have 


different 

timelines) 

the process 

with 


the 

disclosing party. 


(Note 


Communic 

researcher is 

critical 

in 

this 

part 

of 

the 

process becc 

researcher will 

know 


progress 

is occurring 

and 

the 

organizatii 

seriously) 










There are strong 

pros 


and 

cons 

for 

denying 

researchers 

an organization 

states 

that 

"no 

disclosures 


can 

happen unti 

be less risk of 

exploitation, 

but 

there 

may 


also 

be risk 

participate. What 

if 

they 


fear 

a vendor 

"sitting” 

on a 

• What if the 

fix 

takes 


5 

years? 





• Some researchers 

may 


expect very 


fast 

turnarounds 

industries can't 


turn 


on 

a dime. 





Because reasonable 


people 

can 

disagree 

on 

the 

method and 

also be prudent 

to 

have 


a 

defined 

path 


of 

escalation 

appropriate guidance/participation 


from 

the 

regulator 

of 

jurisdictioi 

governments (e.g. 


US 

FDA 

or 

NHTSA 

- 

and 

US 

DHS-ICS- 

medical device, 

the 

FDA 

may 


be best 


poised 

to dete 

ecosystem - as 

well 

as 

the 

optimal safety 

communication strai 
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